We can implement wrapper functions for the following operations:

ValkeyModule_DigestAddStringBuffer
ValkeyModule_DigestAddLongLong
ValkeyModule_DigestEndSequence
ValkeyModule_GetKeyNameFromDigest
ValkeyModule_GetDbIdFromDigest

For example, we can add a function named add_long_long.
This function will look something like:

pub fn add_long_long(&mut self, ll: i64) {
    unsafe {
        // Make a call to raw::RedisModule_DigestAddLongLong API and mutatively pass "self.dig" and "ll" c_longlong type
    }
}

Thanks for the feedback Karthik - updated

To help the caller functions not operate on raw pointers, can we update this to return a ValkeyString type?

Yes, updated

Nit: For all the unsafe functions where we are unpacking the Module API into an optional function, we can use a simpler syntax with expect. Example:

unsafe {
    raw::RedisModule_GetKeyNameFromDigest
        .expect("RedisModule_GetKeyNameFromDigest is not available.")(self.dig)
}

Great feedback - updated

Nice. It would be good to test out this change. We can do this by using the Digest code added and updating this example module (data_type.rs) to implement a callback for the digest function.
https://github.com/valkey-io/valkeymodule-rs/blob/main/examples/data_type.rs

Here is a small example in C where we do the same: https://github.com/valkey-io/valkey/blob/b0f23df16522e91a769c75646166045ae70e8d4e/src/modules/hellotype.c#L296

To add a test, we can add a new function for the "alloc" module here: https://github.com/valkey-io/valkeymodule-rs/blob/main/tests/integration.rs

Sounds good, added

Thank you for adding a test for this Module.

To test the new functionality (digest), we can use the DEBUG command using redis::cmd("DEBUG") on the module data type key and validate that it returns a value without raising any error. This will validate your new callback is being invoked

Thanks for the feedback, updated

Is the name of the Module alloc or data_type?

Alloc, but start_valkey_server_with_module takes in the file name, which is data_type here - I'll update it to be clear, thanks for the feedback.

Thank you for the clarification. That makes sense

Question: does this test (test_alloc_data_type ) get executed when you run the cargo test command? Just want to validate that it runs / passes locally for you

Yes

Thank you for the clarification. That makes sense

Isn't the key name "test_key"? If so, we can update this arg to be "test_key"

You're right, but digest doesn't have any args and uses what's set through alloc.set for its hash input. The syntax looks confusing, but .args is used for both subcommands or as arguments to the first command

Thanks for adding both the tests. This helps add coverage on this new functionality

so we exercise add_string_buffer and end_sequence via Integration Tests. How can we add tests to also test get_key_name, get_db_id and add_long_long?

Thanks for calling this out. I'm thinking that we can follow core and integration test get_key_name, get_db_id and add_long_long

@KarthikSubbarao - your thoughts?

Yes, it makes sense to test all the new functionality that being added, so I agree with your comment, @dmitrypol .

@hahnandrew That makes sense. We can follow the core and have the Digest callback of the example data type use all the new wrapper Digest APIs added.

Here is how the core tests the Module APIs (using the core example module).

Core Unit Tests written in TCL: https://github.com/valkey-io/valkey/blob/2df56d87c0ebe802f38e8922bb2ea1e4ca9cfa76/tests/unit/moduleapi/datatype2.tcl#L183

Core Module: https://github.com/valkey-io/valkey/blob/b0f23df16522e91a769c75646166045ae70e8d4e/tests/modules/datatype2.c#L614

For the get_db_id, notice how they use SELECT to switch data bases. We can do the same and validate that the APIs work as expected